Pd-dev March 2004

pd-dev@lists.iem.at

35 participants
57 discussions

Flext/SndObj problem
by Matthew Laughlin 24 Mar '04

24 Mar '04

Hi all, I'm trying to use the SndObj library with flext but whenever I try to build the code I get linking errors: main.obj : error LNK2001: unresolved external symbol "protected: virtual void __thiscall flext_sndobj::m_signal(int,float * const *,float * const *)" (?m_signal@flext_sndobj@@MAEXHPBQAM0@Z) main.obj : error LNK2001: unresolved external symbol "protected: virtual void __thiscall flext_sndobj::m_dsp(int,float * const *,float * const *)" (?m_dsp@flext_sndobj@@MAEXHPBQAM0@Z) main.obj : error LNK2001: unresolved external symbol "protected: virtual void __thiscall flext_sndobj::Exit(void)" (?Exit@flext_sndobj@@MAEXXZ) main.obj : error LNK2001: unresolved external symbol "protected: virtual bool __thiscall flext_sndobj::Init(void)" (?Init@flext_sndobj@@MAE_NXZ) main.obj : error LNK2001: unresolved external symbol "public: __thiscall flext_sndobj::flext_sndobj(void)" (??0flext_sndobj@@QAE@XZ) Debug/granutron2.dll : fatal error LNK1120: 5 unresolved externals I have #included all the relevant .h files etc. - perhaps I am missing a library module? I appreciate and help! Matt _________________________________________________________________ It's fast, it's easy and it's free. Get MSN Messenger today! http://www.msn.co.uk/messenger

2 1

Fw: [PD-dev] extending the .pd format
by Thomas Grill 24 Mar '04

24 Mar '04

And, btw., i'd like to emphasize that a standardized escape or quoting mechanism for Umlauts and symbols with spaces would be very much appreciated. best greetings, Thomas ----- Original Message ----- From: "Thomas Grill" <t.grill(a)gmx.net> To: "Mathieu Bouchard" <matju(a)sympatico.ca>; <pd-dev(a)iem.kug.ac.at> Sent: Wednesday, March 24, 2004 10:35 AM Subject: Re: [PD-dev] extending the .pd format > Hi Mathieu, > i don't know if you are aware of the way extra information is handled in > Max/Jitter and also flext. > There, the format is as follows > > #X object arg1 arg2 arg3... @key1 val1... @key2 val2.... @key3 val3 .... > etc. > > The key-value pairs are known as "attributes", with the @ of course being a > reserved symbol. > This is very easily implemented without modifications to the patcher format. > > best greetings, > Thomas > > > ----- Original Message ----- > From: "Mathieu Bouchard" <matju(a)sympatico.ca> > To: <pd-dev(a)iem.kug.ac.at> > Sent: Wednesday, March 24, 2004 7:30 AM > Subject: [PD-dev] extending the .pd format > > > > > > Hi, I would need some input on extending the .pd format. I would also like > > that some modifications get made to Pd to support extensibility. Here's > > the plan for now: > > > > 1. "#X connect" lines would take any number of extra arguments, which > > would have to be preserved by attaching an atom list to each connection > > and save that list when saving the connection. Ideally this would have to > > be put in all versions of Pd. Now, miller+devel branches may actually > > just ignore those extra arguments, and the impd branch would do something > > else with it. > > > > 2. all GUI objects should support additional arguments in pretty much the > > same way. > > > > 3. Alternately, (1) and (2) can be replaced by having a new #-code (like > > #E standing for extra) that applies to the last #X. This would be > > especially good for adding properties to GUI objects that already have a > > use for any number of arguments (messageboxes, objectboxes themselves, > > and comments). > > > > 4. In any case, I think it would be good to have those extras as key/value > > pairs, because 23 unnamed arguments (#X obj 0 0 vsl blah blah blah) is > > already a bit hard to follow sometimes, and it sounds silly to me to add > > more of those unnamed arguments, especially since in most cases, default > > values still would be used, just like they already are in the case of half > > of the 23 unnamed arguments right now. > > > > 5. There's a problem with the above idea (4) when it comes to counting a > > list as a value. One way to resolve this is to introduce sublists, which > > would be a good idea anyway, and use the {} characters (that are currently > > dropped, and so unused) for that purpose, just like how they are used in > > jMax2 and Tcl already (or parens in LISP, or [] in many others). > > > > 6. However I don't know how much code would have to be changed for (5) to > > be completed. If I didn't care about compatibility, I would introduce {}'s > > all over the place, but if I have to make it easier for other > > (miller+devel) branches, then i'd ask to only support them in #E's for > > now, and delay their other potential uses in the rest of Pd (inside normal > > "#X obj" arguments, etc), though using parens with spaces around them (in > > GF/Pd) still looks silly anytime. > > > > > > > > Ok, the above are my most important ideas, but below are some extra > > nonneglectible ideas that I'm less sure what to do about. > > > > > > > > 7. If doublequotes changed meaning to quoting symbols in pretty much > > C/Tcl/etc allow, it would be an incompatibility, but I suspect the end > > result of most of the affected patches would actually remain the same, > > just going through different semantics, such that "foo bar" would just be > > a 7-character symbol instead of two 3-character symbols. > > > > 8. However I would prefer doublequotes to mean _string literals_ instead, > > and maybe use some other character for symbol quoting: LISP uses [], but > > LISP isn't too familiar to most Pd users anyway. I might suggest backticks > > or singlequotes. String literals might be difficult to introduce neatly > > into Pd, because it would be great if they could be used (magically) > > instead of symbols whenever possible, and have automatic conversion, but I > > guess all the code checking for T_SYMBOL won't support it... > > > > ________________________________________________________________ > > Mathieu Bouchard http://artengine.ca/matju > > > > > > _______________________________________________ > > PD-dev mailing list > > PD-dev(a)iem.at > > http://iem.at/cgi-bin/mailman/listinfo/pd-dev > > > > > > > _______________________________________________ > PD-dev mailing list > PD-dev(a)iem.at > http://iem.at/cgi-bin/mailman/listinfo/pd-dev > >

1 0

"tracking third-party sources" in cvs
by Hans-Christoph Steiner 22 Mar '04

22 Mar '04

So I was just reading the cvs docs and I came across this handy chapter: 13. Tracking third-party sources http://www.cvshome.org/docs/manual/cvs-1.11.14/cvs_13.html#SEC104 This seems to be the way that we should be tracking code that is not maintained in the pure-data.sf.net CVS. I believe guenter was talking about switching the pd sources to this method, and I think we should use this method for the externals as well. Basically, the code from the original source is maintained in a separate branch, while we work on the MAIN branch (which is the default). Then we 'cvs import' new versions from the source into that separate branch and merge changes into the MAIN branch. .hc

4 6

linuxevent: EV_RST => EV_SYN
by Frank Barknecht 22 Mar '04

22 Mar '04

Hallo, I see, that linuxevent.c in CVS was changed to exclude EV_RST which isn't defined in newer input.h headers anymore. I wonder, if this is the correct way to solve this problem. input.h does define EV_SYN now as being zero: /* * Event types */ #define EV_SYN 0x00 ... I don't know what this event does and if it's important to still include them, but maybe someone else does? At least, just commenting out EV_RST feels a bit wrong... ciao -- Frank Barknecht _ ______footils.org__

3 3

multiple def's in m_pd.h?
by James Tittle II 21 Mar '04

21 Mar '04

hiya, ...is there a reason why there are multiple def's of t_inlet & t_outlet in m_pd.h? ...around 147: EXTERN_STRUCT _outlet; #define t_outlet struct _outlet EXTERN_STRUCT _inlet; #define t_inlet struct _inlet ...and around 341: /* ----------------- patchable "objects" -------------- */ EXTERN_STRUCT _inlet; #define t_inlet struct _inlet EXTERN_STRUCT _outlet; #define t_outlet struct _outlet ...? jamie

1 0

build flext as a dynamic library problems
by Georg Holzmann 21 Mar '04

21 Mar '04

Hallo! I try to build flext as a dynamic library (because the stand-alone externals are really big) and use flext0.4.5 and MSVC6 on WinXP. I've tried to add UFLAGS=/DFLEXT_SHARED in config-pd-msvc, but I got a lot of errors: flbase.cpp source\flbase.cpp(40) : warning C4273: 'public: static struct flext_hdr * flext_ obj_shared::m_holder' : inconsistent dll linkage. dllexport assumed. source\flbase.cpp(40) : error C2491: 'flext_obj_shared::m_holder' : definition o f dllimport static data member not allowed source\flbase.cpp(41) : warning C4273: 'public: static struct _symbol const * co nst flext_obj_shared::m_holdname' : inconsistent dll linkage. dllexport assumed (... and so on...) source\flbase.cpp(54) : warning C4273: 'flext_obj_shared::flext_obj_shared' : in consistent dll linkage. dllexport assumed. source\flbase.cpp(71) : warning C4273: 'flext_obj_shared::~flext_obj_shared' : i nconsistent dll linkage. dllexport assumed. source\flbase.cpp(76) : warning C4273: 'Init' : inconsistent dll linkage. dllex port assumed. source\flbase.cpp(77) : warning C4273: 'Finalize' : inconsistent dll linkage. d llexport assumed. source\flbase.cpp(78) : warning C4273: 'Exit' : inconsistent dll linkage. dllex port assumed. source\flbase.cpp(81) : warning C4273: 'DefineHelp' : inconsistent dll linkage. dllexport assumed. source\flbase.cpp(99) : warning C4273: 'GetParamSym' : inconsistent dll linkage. dllexport assumed. NMAKE : fatal error U1077: 'cl' : return code '0x2' Stop. NMAKE : fatal error U1077: 'C:\PROGRA~1\MICROS~3\VC98\BIN\NMAKE.EXE' : return co de '0x2' Stop. Do I need the additional Processor Pack for MSVC6 to compile flext as a dynamic library? Or is the compiler flag wrong? Thanks for any advice, LG Georg -- +++ NEU bei GMX und erstmalig in Deutschland: TÃV-geprÃ¼fter Virenschutz +++ 100% Virenerkennung nach Wildlist. Infos: http://www.gmx.net/virenschutz

2 2

0.37.1 bug: $0 sometimes saving as number (still)
by Hans-Christoph Steiner 21 Mar '04

21 Mar '04

I know that there was a bug in test versions of 0.37.1 where $0 would be saved as the numerical ID. Well, it seems to be back. $0 remains $0 in most of the patches I have tried recently, except for this one patch of mine, xp4pd-client.pd. I have tried it on both of the MacOS X installer versions that I posted recently. Both are based on Miller's 0.37.1 source, one was built on Tcl 8.5 and the other Tcl 8.4. Both had this problem. My bro was running this same patch on Windows using 0.37.1 and he did not have this problem. --------------------------------------- xp4pd-client.pd ------------------------------------------- #N canvas 276 94 628 690 10; #X obj 163 300 netclient; #X msg 10 201 disconnect; #X symbolatom 483 84 0 0 0 2 ClientID $0-ClientID -; #X obj 101 153 bng 25 250 50 0 empty empty empty 0 -6 0 8 -4033 -1 -1; #X obj 10 153 bng 25 250 50 0 empty empty empty 0 -6 0 8 -258049 -1 -1; #X obj 10 107 netreceive 11111; #X obj 240 300 tgl 17 0 empty empty connection 20 8 1 8 -188399 -1 -1 0 1; #X obj 8 6 cnv 15 600 60 empty empty xp4pd_client 20 12 1 18 -233017 -66624 0; #X text 9 74 [netreceive 11111] is for receiving connect/disconnect from the command line \, or from another machine.; #X obj 308 159 tgl 15 0 empty empty empty 0 -6 0 8 -262144 -1 -1 0 1; #X msg 308 177 capture \$1; #X msg 308 140 1; #X obj 393 271 bng 15 250 50 0 127.0.0.1 empty empty 0 -6 0 8 -262144 -1 -1; #X obj 234 498 niagara 1; #X obj 292 526 spigot; #X msg 329 495 0; #X msg 436 495 1; #X obj 329 433 niagara 1; #N canvas 125 271 666 538 shared_patch 0; #X restore 415 138 pd shared_patch; #X obj 308 198 tot shared_patch; #X obj 292 588 s pd-shared_patch; #X obj 163 428 s $0-ClientID; #X obj 436 433 r $0-ClientID; #X msg 428 201 set \$1; #X obj 428 182 r $0-ClientID; #X obj 393 223 prepend; #X obj 329 452 symbol; #X obj 234 408 trigger anything anything; #X obj 329 475 select localhost; #X msg 153 122 127.0.0.1; #X obj 124 184 symbol; #X msg 163 269 send whoami; #X obj 163 376 route whoami; #X symbolatom 124 203 15 0 0 0 - - -; #X obj 163 408 symbol; #X obj 10 133 route disconnect; #X obj 393 242 prepend send; #X text 303 48 (C) at.or.at - released under the GNU GPL; #X msg 153 144 pdbox.at.or.at; #X text 49 621 needs [prepend] from cyclone \, [tot] from toxy \, [niagara] from zexy \, and [netclient] from maxlib; #X text 204 9 (connect to pdbox.at.or.at for a public server); #X msg 124 221 connect \$1 42776; #X msg 221 320 \; pd-shared_patch vis \$1 \;; #X msg 22 539 \; pd-shared_patch selectall \; pd-shared_patch key 1 8 0 \; pd-shared_patch key 0 BackSpace 0; #X obj 10 180 t b b; #X connect 0 0 32 0; #X connect 0 1 6 0; #X connect 0 1 31 0; #X connect 0 1 42 0; #X connect 1 0 0 0; #X connect 3 0 33 0; #X connect 4 0 44 0; #X connect 5 0 35 0; #X connect 9 0 10 0; #X connect 10 0 19 0; #X connect 11 0 9 0; #X connect 13 1 14 0; #X connect 14 0 20 0; #X connect 15 0 14 1; #X connect 16 0 14 1; #X connect 17 0 26 0; #X connect 19 2 25 0; #X connect 19 3 11 0; #X connect 22 0 28 1; #X connect 23 0 25 0; #X connect 24 0 23 0; #X connect 25 0 36 0; #X connect 26 0 28 0; #X connect 27 0 13 0; #X connect 27 1 17 0; #X connect 28 0 15 0; #X connect 28 1 16 0; #X connect 29 0 30 0; #X connect 30 0 33 0; #X connect 31 0 0 0; #X connect 32 0 34 0; #X connect 32 1 27 0; #X connect 33 0 41 0; #X connect 34 0 21 0; #X connect 35 0 4 0; #X connect 35 1 3 0; #X connect 36 0 12 0; #X connect 36 0 0 0; #X connect 38 0 30 0; #X connect 41 0 0 0; #X connect 44 0 1 0; #X connect 44 1 43 0;

1 1

impd
by Thomas Grill 19 Mar '04

19 Mar '04

Hi Mathieu, right now i'm trying to run your impd on Windows.... i hope it's ok that i checked in some minor changes into the cvs allowing for compilation with Microsoft Visual C++. It starts up, but then after opening a new patcher (a like that gray background) i can't do anything with it. Even closing results in a "Error in TCL Script": Error: can't read "context": no such variable. best greetings, Thomas

2 1

Re: [PD] Impd
by Mathieu Bouchard 19 Mar '04

19 Mar '04

On Sun, 7 Mar 2004, John Lamb wrote: > >> While you're branching, could you please replace all instances of exp) > >> exp, and exp- with exp2) exp2, and exp2- respectively in > >> extra/expr~/vexp.c and vexp_if.c? Ok, I finally replaced all instances of "exp" (whole-word) with "expr" in those two files. However i don't know what you mean about "exp)" and "exp2" ... I tried compiling with gcc 3.3 and it shows warnings about "exp" only, and then it crashes trying to produce the .o ... (I normally use gcc 3.2.2) On Sun, 14 Mar 2004, John Lamb wrote: > GOP patches that use the vslider object don't work too well. I am > including one in particular that I made for testing purposes that fails > spectacularly. ;) > In addition, the "Test Audio and MIDI" option in the "Media" menu bugs > out and is unusable, it prints this error message: > Tcl Error: can't read "fields(vdl)": no such element in array Ok, I fixed this, but then, I added many new bugs, as I rewrote almost all dialog box code. I hope to get everything stable again ASAP... > I love the arrows; even though I know inlets are on the top and > outlets are on the bottom, the arrowheads do clear things up in > complicated patches. It's also good for giving people who don't know Pd at all a vague sense of what's going on... ________________________________________________________________ Mathieu Bouchard http://artengine.ca/matju

2 1

devel branch for 'externals'
by Hans-Christoph Steiner 18 Mar '04

18 Mar '04

There is a bunch of code in the 'externals' section of the CVS that is not maintain there (maxlib, motex, pdogg I think, etc.). So I was thinking that it would make sense to make that code read-only, then make a branch like "devel_0_37" for 'pd', maybe calling it just "devel" or whatever. But I think it would be good to have a standard branch for modification of such code. This would make it easier to maintain code in the CVS when the creator doesn't want to maintain it in the CVS. Thoughts? Comments? .hc

4 6

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 March 2004