Pd-dev January 2009

pd-dev@lists.iem.at

25 participants
84 discussions

[ pure-data-Patches-2510152 ] useless dummy canvas in pd main window ?
by SourceForge.net 15 Jan '09

15 Jan '09

Patches item #2510152, was opened at 2009-01-15 15:18 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=2510152&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: useless dummy canvas in pd main window ? Initial Comment: there is a line: canvas .dummy -height 2p -width 6c in pd.tk (u_main.tk). for what is it needed ? as at least on linux the pd main window doesnt look "nice" when the dummy canvas is in (see attached screenshot, comparing with and without the dummy canvas) if its not needed: 129d128 < canvas .dummy -height 2p -width 6c 132c131 < pack .controls .dummy -side top -fill x --- > pack .controls -side top -fill x ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=2510152&group_…

1 0

[ pure-data-Bugs-2501602 ] "find $1" crashes when "whole word" is unchecked
by SourceForge.net 15 Jan '09

15 Jan '09

Bugs item #2501602, was opened at 2009-01-12 16:45 Message generated for change (Settings changed) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2501602&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: v0.42.2 >Status: Pending >Resolution: Fixed Priority: 6 Private: No Submitted By: IOhannes m zmlnig (zmoelnig) Assigned to: Miller Puckette (millerpuckette) Summary: "find $1" crashes when "whole word" is unchecked Initial Comment: with Pd-0.42 we can finally search for $1 literals (thanks) unfortunately, this can crash Pd, if used with the new "whole word" checkbox in the find-window unchecked. steps to reproduce: - create object containing [f $1] - Find "$1" with 'whole world' unchecked -> CRASH see attached patch to do this programmatically. tested on linux and osx with Pd-0.42.2 ---------------------------------------------------------------------- >Comment By: IOhannes m zmlnig (zmoelnig) Date: 2009-01-15 15:06 Message: fixed in 0.42.3 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2501602&group_…

1 0

[ pure-data-Bugs-2501709 ] [any2string] converts non-ascii chars to negative values
by SourceForge.net 15 Jan '09

15 Jan '09

Bugs item #2501709, was opened at 2009-01-12 17:17 Message generated for change (Comment added) made by mukau You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2501709&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: externals Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Roman Haefeli (reduzent) Assigned to: Nobody/Anonymous (nobody) Summary: [any2string] converts non-ascii chars to negative values Initial Comment: belongs to: moocow/pdstring/any2string non-ascii characters (such as the umlaute 'äöü') are converted to negative values. instead of i, [any2string] converts to i-256, thus the negative values. [string2any], OTOH, does seem to work correctly. '246' is converted to 'ö'. this on pd-vanilla linux with: pdstring version: 0.06 by Bryan Jurish ---------------------------------------------------------------------- Comment By: Bryan Jurish (mukau) Date: 2009-01-13 21:44 Message: > or even simpler, it could be done with a [mod 256]. ... oops, got me! > if you think, that my point is somehow valid your point is certainly valid: I would prefer to have made [any2string] output unsigned byte values from the beginning, it's really just compatibility issues nagging at me. > what about having a third argument: 0=signed, 1=unsigned ? also easy, but a bit klunky ... maybe an additional object [any2ustring] for unsigned chars? perhaps we should just check pd-list and see if anyone needs signed chars from [any2string] ... ---------------------------------------------------------------------- Comment By: Roman Haefeli (reduzent) Date: 2009-01-13 20:38 Message: or even simpler, it could be done with a [mod 256]. two reasons, why i want it to have reported and even would prefer it to be changed: 1) it's rather tedious to do it in userspace, since [any2string] outputs lists and for conversion, those need to be serialized, converted and re-packed again. this is not only a complex task to do, it is also very expensive. there is a quick table based 'serialization algorithm, though, but re-packing with only vanilla classes is rather expensive, and exponentially expensive with growing list length in terms of moved atoms [someone please correct me]. 2) many classes, that i would find useful to be used together with [any2string] expect 'unsigned chars', that is to say [tcp*], [udp*], [comport] and probably more. as i see it, we have a clash of conventions here and personally i am not able to come up with a good argument for having 'signed chars'. if you think, that my point is somehow valid, so please lets turn that apparently bogus bug report into a feature request: what about having a third argument: 0=signed, 1=unsigned ? ---------------------------------------------------------------------- Comment By: Bryan Jurish (mukau) Date: 2009-01-13 14:46 Message: This is known behavior, due to the C type used internally ("char", which in C semantics means "signed char"). Non-ASCII characters should be accepted by [string2any] in both "signed char" (ö = -10) and "unsigned char" (ö = 246) format, though. It would be easy to change [any2string] to output only "unsigned char" values in the range (0..255) rather than "signed char" values in the range (-128..127), but I don't yet see any pressing need to do so, since it would break patches that rely on this behavior (if there are any). As a workaround, you can use [moses] to detect negative values and [+ 256] to bash them to values in the (0..255) range if you need to. -Bryan ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2501709&group_…

3 2

pd-devel status report #2
by Hans-Christoph Steiner 15 Jan '09

15 Jan '09

To start with, I am working on Ubuntu/Intrepid/i386 and Mac OS X 10.5.6/Intel. First, it works! You can open patches and run them! You can create patches, but its pretty glitchy still. I am working on getting saving working right now. So far, most of the work has been on rearchitecting the GUI and startup procedure. This will make it much easier to do all sorts of fun stuff with the GUI, which is the inspiration behind this effort. You can now start Pd either from Wish (Tk's shell for the GUI) or the 'pd' program. This gives us a convenient mechanism for checking whether there is already an instance of Pd running. Basically, if you start the Pd GUI first, it will only allow one instance to run. But if you start 'pd', which then starts the GUI, you can run many instances. If you would like to try it yourself, here's how: svn co http://pure-data.svn.sourceforge.net/viewvc/pure-data/branches/pd-devel/0.4… cd 0.41.4/src autoconf ./configure make ../bin/pd -OR- wish ../bin/pd.tk In other news, there have been some minor changes to the C code. Part of the idea of this effort was to only make changes to the Tcl/GUI side. I think the C changes so far are in keeping with that spirit: - deleted t_tk.h, t_tkcmd.c, t_main.c - removed #include "t_tk.h" from the iemguis (g_*.c) (unneeded in any version of Pd) - changed pdgui start line in s_inter to work on GNU/Linux One thing that will have to change is s_inter.c since it handles the startup procedure. Mostly, I think it'll be drastically simplified as most of the #ifdefs can be removed. This will mostly happen when things get ported to Windows. If you want to get involved there are lots of ways to contribute. Here are somethings that would be pretty easy and self-contained to take on, ranging from small to bigger: - performance testing (to make sure the Tcl networking is up to snuff, it seems fast) - find panel - send message panel - restructure Pd window for cleaner UI and code - canvas scrollbar logic - unified preference panel with tabs (like standard ones on GNOME, Mac OS X, and Windows) - help browser - overall naming/organization scheme for variables, functions, and packages Or what do you want to work on? .hc ---------------------------------------------------------------------------- "[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore

1 0

[ pure-data-Bugs-2507851 ] messed-up paths with pd_install
by SourceForge.net 14 Jan '09

14 Jan '09

Bugs item #2507851, was opened at 2009-01-14 21:07 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2507851&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pd-extended Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Holger (waffenladen) Assigned to: Hans-Christoph Steiner (eighthave) Summary: messed-up paths with pd_install Initial Comment: Since the latest pd-merge, when I do cd packages/ make pd_install or some pd files get installed to double the DESTDIR-path, i. e. packages/build/home/hb/pd-extended/packages/build/usr/lib... that is because in pd/src/makefile.in all entries getting paths from libpddir are prefixed with $(DESTDIR), but libpddir gets already prefixed with DESTDIR in Makefile.buildlayout... so I patched pd/src/makefile.in (patch attached). Hope I'm not the only one with this problem... Cheers, Holger ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2507851&group_…

1 0

-guiport vs other arguments
by Hans-Christoph Steiner 14 Jan '09

14 Jan '09

So I have startup in both directions working, ('pd.tk' starts 'pd', and 'pd' starts 'pd.tk'). This means you can choose which wish shell to use on any platform, and it'll use that one. Here's how: wish /path/to/pd.tk This means you can easily use any 'wish' and run Pd with it. It also makes it possible on Mac OS X to run pd in the Pd.app Aqua GUI, or run it in the wish X11 GUI. Hopefully it makes the code cleaner too, much fewer #ifdefs. Now I have a question: it seems that if I start 'pd' with -guiport, then it seems to ignore any other command line arguments and dumps the '-help' text. Any reason why it shouldn't be possible to use -guiport with all the rest of the options? Anyone know how to do this? :D .hc ---------------------------------------------------------------------------- "[T]he greatest purveyor of violence in the world today [is] my own government." - Martin Luther King, Jr.

3 5

pd-devel status report
by Hans-Christoph Steiner 13 Jan '09

13 Jan '09

Hey all, http://pure-data.svn.sourceforge.net/viewvc/pure-data/branches/pd-devel/0.4… If you haven't followed the SVN check-ins, Chun and I have been working on rewriting the Tcl side of things. Things are structured into some Tcl packages, but I am not sure they are named or organized correctly just yet, so feedback would be good. Also, Tcl's syntax can get obfuscated fast, so I am trying to keep things pretty easy to read for non-Tcl programmers. The exciting news (for me at least) is that I have a working Tcl implementation of the network side of the GUI, replacing t_tkcmd.c, t_tk.h, and t_main.c. It is now using Tcl's catch{} on incoming commands so that invalid Tcl commands, like typing a '{' in current Pd, can be handled cleanly. If anyone is ready to join in, there are many things that people could work on: - internationalization using msgcat and standard .po files - unified preference panel with tabs (like standard pref panes on GNOME, Mac OS X, and Windows) - flexible key binding code so that people can easily experiment with all these ideas (this is started in pd_bindings.tcl) - restructure Pd window for cleaner UI and code - canvas scrollbar logic and more.... .hc

4 7

proposed C change: consistent naming
by Hans-Christoph Steiner 13 Jan '09

13 Jan '09

I think it would make a lot of sense to rename a few functions/procs so that they all match the pd message, but I haven't does this yet in pd-devel. For example: "mouse" message: Tcl: pdtk_canvas_click -> pdtk_canvas_mouse C: canvas_mousedown -> canvas_mouse "mouseup" message Tcl: pdtk_canvas_mouseup C: canvas_mouseup This makes the code much easier to follow, and therefore debug and improve :) .hc ---------------------------------------------------------------------------- If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it. - Thomas Jefferson

1 0

wishlist: pd being able to connect to a remote pd-gui
by IOhannes m zmoelnig 13 Jan '09

13 Jan '09

since we are talking about guiports and stuff like that, i now find the time to ask a question i always wanted to ask: would it make sense to add an argument to pd so it could connect to a remote pd-gui? currently we can only specify an arbitrary port on the localhost via: "pd -guiport <portnumber>" it would be nice (for things like peerdata) to do something like: "pd -guiport <port> -guihost <host>" or even "pd -gui <host>:<port>" and "pd -gui <port>" and "pd -gui <host>" (or was it the other way round?= fg,asdr IOhannes

2 2

[tcpsocketserver] - a protocol-aware wrapper around [tcpserver]
by Roman Haefeli 13 Jan '09

13 Jan '09

hi all, hi martin as pointed out in a previous thread, it's tricky to use [tcp*] object classes for transporting packet oriented protocols, such as OSC or FUDI. when dealing with [tcpserver], the situation gets even more tricky. when several clients are connected to a [tcpserver] and they all send data in a packet oriented protocol simultaneously, the packets from several sockets might get mixed up on the server side, since tcp is not packet-aware and frames sent by clients might get splitted (or even concatenated). the only way i found to overcome that problem, was to make [tcpserver] protocol-aware, so that it keeps track of the several incoming streams and creates protocol-compliant packets out of them. on the other hand, i wanted a generic solution, that could be extended with support for more protocols than initally implemented. that is why i made: [tcpsocketserver <protocol> <port>] from what i understand, it works the same way, as other servers for a packet-oriented protocol work. whenever a new client connects, [tcpsocketserver] dynamically creates an instance of a socket handler, an abstraction, that is called [ŧcpsocket.PROTOCOLNAME]. all data received on that socket is sent to the appropriate handler. the handler contains the code, that forms proper packets from the incoming stream and sends the packets back to [tcpsocketserver]. no matter in what order and in what frame sizes the streams are received, [tcpsocketserver] only outputs valid, protocol-compliant packets. yet, two protocols are supported: OSC and FUDI. support for the protocol FOO can be added by creating another socket handler, naming it tcpsocket.FOO.pd and putting in the code, that makes FOO-packets out of the incomding stream. then it can be called with [tcpsocketserver FOO 1234]. i hope this all makes sense to you. comments are welcome, of course. if you, martin, find it useful, i'd be glad, if this could make it into the mrpeach library. my main purpose for doing this was to be able to transmit OSC packets in a multiclient<->server environment, which is finally working well since [tcpsocketserver]. http://www.romanhaefeli.net/software/pd/tcpsocketserver.tar.gz roman ___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

4 5

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Pd-dev January 2009