Pd-dev June 2008

pd-dev@lists.iem.at

24 participants
90 discussions

[ pure-data-Bugs-2004979 ] hid defaults to debugging (flood of "hid_get_events")
by SourceForge.net 21 Jul '08

21 Jul '08

Bugs item #2004979, was opened at 2008-06-28 06:28 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2004979&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: externals Group: None >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Frank Barknecht (fbar) Assigned to: Hans-Christoph Steiner (eighthave) Summary: hid defaults to debugging (flood of "hid_get_events") Initial Comment: It seems, [hid] still defaults to have debugging on which results in a flood of "hid_get_events" messages to the console, when polling is on, unless one sends [debug 0( to [hid] Also see http://lists.puredata.info/pipermail/pd-list/2007-01/046275.html ---------------------------------------------------------------------- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-06-28 13:14 Message: Logged In: YES user_id=27104 Originator: NO One Pd-extended 0.40.3 is released, I'll merge all of the changes into trunk (this is a fairly standard way to deal with release branches). In the meantime, I recommend you use the release version. ---------------------------------------------------------------------- Comment By: Frank Barknecht (fbar) Date: 2008-06-28 08:05 Message: Logged In: YES user_id=569446 Originator: YES I'm using the "trunk", not a branch. I did a "cd trunk/externals; make hid" as told in hid's README. It still starts with debugging then. ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-06-28 06:58 Message: Logged In: YES user_id=27104 Originator: NO I just fixed this and some other bugs and annoyances with [hid]. This should be fixed by this commit, let me know if it is not: http://pure-data.svn.sourceforge.net/viewvc/pure-data/branches/pd-extended/… ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2004979&group_…

4 12

removing string types from pd-extended release
by Hans-Christoph Steiner 11 Jul '08

11 Jul '08

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

5 13

svn:externals, pd-extended, SVN and the goal of it all
by Hans-Christoph Steiner 09 Jul '08

09 Jul '08

Hey, So what should be the core mission of the pure-data repository? It looks like it is time to have that discussion again. I see it as a gathering of code and docs that are intended to be built using a common build system (aka Pd-extended build system). As for Pd-extended, I think it is a mistake (almost all my fault) including so many things in the package. It is now clear to me that makes more sense to have a distro that includes only the very stable libraries, then to make Pd fully support external libdirs, including shared libs, help patches, example patches, manuals, etc. I think then there could be a simple distro system like Eclipse has for managing plugins. (Basically, there is a simple format for posting a library to a website. The user then adds the repo URL to the program, which then has a browser for all available installation options and updates). I guess this was a bit vague and wandering, but it seems that there is a discussion that needs to be had. .hc ------------------------------------------------------------------------ ---- 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

6 8

svn:externals
by Hans-Christoph Steiner 09 Jul '08

09 Jul '08

One of the original goals of the "pure-data" common source code repository was to be able to easily find Pd code. I think that now that there is a lot more development activity, I think that this no longer makes sense as a technique for cataloging code. I think that a wiki page on puredata.info would make a lot more sense, or perhaps other things. Now people are starting to use svn:externals. I support the goal of findability; I do not think that svn:externals is the best way to do that. I think svn:externals is a tool for very specific cases. The pdmtl svn:externals was already causing problems because it uses a non-official TLS cert. This can break autobuilds, for example, and cause lots of headaches and support requests. I don't know of any other project that uses svn with svn:externals as a method for cataloging code. So before we fill up the pure-data SVN with svn:externals links, I think we should make it clear what they are good for. .hc ------------------------------------------------------------------------ ---- Access to computers should be unlimited and total. - the hacker ethic

3 6

[range] from maxlib
by Roman Haefeli 07 Jul '08

07 Jul '08

hi all why is [range], that was initially part of maxlib, moved to <pd-svn>/externals/deprecated ? who decides, what is deprecated and what not? roman ___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

3 10

Reliable MIDI library for Windows?
by PSPunch 03 Jul '08

03 Jul '08

Hi, I understand that MIDI objects under Windows is said to be less stable than Linux, due to the MIDI functions under Windows API that Pd relies on. If I were to write my own MIDI I/O external for Windows, are there such things as alternative MIDI libraries or APIs available, or does Windows not allow you to access MIDI devices it recognizes without running data through its interface? Like some posts I made about a month back, my initial goal is to get raw MIDI in&out working, this time on Windows. Any hints appreciated. Thanks. -- David Shimamoto

2 4

Re: [PD-dev] Reliable MIDI library for Windows?
by PSPunch 01 Jul '08

01 Jul '08

Hi Isidro, Thank you for the info. Reading the library you had mentioned, I got the impression that it currently does not support MIDI functions for Windows. Similar to some of my posts from a while back, I am trying to learn what it takes to get Sysex working, this time under Windows. Homebrew I/O devices are cool indeed. Meanwhile, there are a great variety of MIDI devices available in shops which require Sysex messages to fully utilize them. I find it a bit sad that I cannot easily prepare abstractions to work these devices. For Linux, Sysex ([midiout]) seemed to be simply "fixed" in recent versions of Pd. What more does it take to work it under Windows? So far what I've learned from observation is that a C function, "midiOutLongMsg" must be utilized to send Sysex messages. In the current code I am reading (0.41-4) there are only midiOutShortMsg. Haven't looked in to receiving yet. I will have to proceed with reading the internals a bit more before I can write anything myself. -- David Shimamoto > If you don´t want to use the DirectX API, you could > use > sndlib by Bill Schoesttadt. Sndlib can be obtained at > CCRMA of Stanford and allows Audio and Midi I/O. The > MIDI functions are sparse but may match what you are > looking for your purposes. > This is the CCRMA WEB: > http://ccrma.stanford.edu > Best > Isi > > --- PSPunch <shima(a)pspunch.com> wrote: > >> Hi, >> >> >> I understand that MIDI objects under Windows is said >> to be less stable >> than Linux, due to the MIDI functions under Windows >> API that Pd relies on. >> >> If I were to write my own MIDI I/O external for >> Windows, are there such >> things as alternative MIDI libraries or APIs >> available, or does Windows >> not allow you to access MIDI devices it recognizes >> without running data >> through its interface? >> >> Like some posts I made about a month back, my >> initial goal is to get raw >> MIDI in&out working, this time on Windows. >> >> Any hints appreciated. >> Thanks. >> >> -- >> David Shimamoto >> >> >> _______________________________________________ >> Pd-dev mailing list >> Pd-dev(a)iem.at >> http://lists.puredata.info/listinfo/pd-dev >> > > > > > >

1 0

[ pure-data-Bugs-2007191 ] [sssad] does not create on pd-extended
by SourceForge.net 01 Jul '08

01 Jul '08

Bugs item #2007191, was opened at 2008-07-01 07:44 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=2007191&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: hardoff (hardoff) Assigned to: Hans-Christoph Steiner (eighthave) Summary: [sssad] does not create on pd-extended Initial Comment: there is a similar bug report below, but here are further details: creating a [sssad] object in pd-extended causes the following error in the console: libdir_loader: added 'sssad' to the canvas-local objectclass path libdir_loader: added 'sssad' to the canvas-local objectclass path libdir_loader: added 'sssad' to the canvas-local objectclass path ...about 1000 times, and then finally says: error: maximum object loading depth 1000 reached sssad ... couldn't create several people have suggested that there is a glitch in the libdir loader that won't allow for an abstraction to have the same name as its enclosing folder. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2007191&group_…

1 0

[ pure-data-Bugs-1965894 ] sssad-help.pd error
by SourceForge.net 01 Jul '08

01 Jul '08

Bugs item #1965894, was opened at 2008-05-17 18:55 Message generated for change (Comment added) made by hardoff You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1965894&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: eerne (eerne) Assigned to: Nobody/Anonymous (nobody) Summary: sssad-help.pd error Initial Comment: with Pd-0.40.3-extended-20080516-macosx104-i386.dmg the sssad-help.pd file does not work out of the box. libdir_loader: added sssad to the canvas-local path sssad key ... couldn't create libdir_loader: added sssad to the canvas-local path sssad key ... couldn't create libdir_loader: added sssad to the canvas-local path sssad key ... couldn't create libdir_loader: added sssad to the canvas-local path sssad key ... couldn't create sssad-example ... couldn't create ---------------------------------------------------------------------- Comment By: hardoff (hardoff) Date: 2008-07-01 07:43 Message: Logged In: YES user_id=1816568 Originator: NO creating a [sssad] object in pd-extended causes the following error in the console: libdir_loader: added 'sssad' to the canvas-local objectclass path libdir_loader: added 'sssad' to the canvas-local objectclass path libdir_loader: added 'sssad' to the canvas-local objectclass path ...about 1000 times, and then finally says: error: maximum object loading depth 1000 reached sssad ... couldn't create several people have suggested that there is a glitch in the libdir loader that won't allow for an abstraction to have the same name as its enclosing folder. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2008-05-29 08:03 Message: Logged In: NO I named the private subdirectory "_sssad" just randomly, loosly inspired by Pyton's convention of using underscores for private stuff. I wasn't thinking of some libdir conflict at that time at all. As the sssad "library" consists of only one object I didn't consider namespacing for it at all. I haven't used libdirs so far, but I think, objects which have the same name as the libdir should be possible as well. --Frank (not logged in, but believe me it's me) ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2008-05-29 00:58 Message: Logged In: YES user_id=27104 Originator: NO so the problem is that the libdir for sssad is currently called 'sssad'. Since the main object is also called 'sssad', there is a nameconflict. Frank must have found this himself, since he named the included folder '_sssad'. I am not really sure how to solve this, except include sssad in a different library. Any suggestions? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1965894&group_…

1 0

Re: [PD-dev] Problem Compiling Ratts on Cygwin
by Bryan Jurish 30 Jun '08

30 Jun '08

moin Daniel, moin list ... cc'ing this message to pd-dev, as discussed ... for those of you listers who may have missed the beginning of this discussion (e.g. pretty much all of you), we're trying to get [ratts] built on a windoof box, without much success. not being a windoof user myself, i'd appreciate any tips anyone could offer regarding external compilation on such machines; in particular CFLAGS, LDFLAGS, LIBS, etc etc... some relevant snippets of the discussion to date follow... On 2008-06-29 01:00:15, "daniel c. howe" <dhowe(a)mrl.nyu.edu> appears to have written: > Bryan Jurish wrote: >> moin Daniel, >> >> it just occurred to me that pd builds on cygwin are notoriously >> difficult: did you actually get pd to build and run? Quoting from >> http://puredata.info/docs/developer/WindowsXPI386 : >>> Pd doesn't build in Cygwin. You have to use MSYS. > nope, wasnt able to get it to build via cygwin... so just running a > binary so far hmm, where did you get the binary? are you sure it wasn't built e.g. with MSYS (or worse yet with MSVC) and not with cygwin at all? for msys builds i could potentially try out some of these hacks myself on the pd build farm machine: are you maybe running a pd-extended build? >> at any rate, assuming you got pd built on cygwin, it would help to know >> how the "standard" externals got built (a make log from pd/src and >> especially pd/extra would be helpful here): this should give us a good >> idea of the flags used. ... again, for msys builds, we could probably lift the relevant flags from the pd-extended build system. > same error after running autogen: > ================================== > ratts.c:1: warning: -fPIC ignored for target (all code is position > independent) ok, we can leave out -fPIC, but it shouldn't hurt to leave it in... > gcc -O2 -fno-strict-aliasing -fPIC -Wall -Winline -o ratts.dll > -export_dynam > ic -shared parwave.o klatt_frame.o elements.o squeue.o dsqueue.o > rholmes.o phfea > t.o pd_holmes.o alhash.o phtoelm.o pd_phtoelm.o darray.o phoneutils.o > trie.o tex > t.o english.o saynum.o ratts_keyval.o suspect.o ASCII.o klatt~.o > holmes.o holmes > -feat.o holmes-mask.o phones2holmes.o guessphones.o number2text.o > rattshash.o ra > ttstok.o toupper.o spellout.o ratts.o > klatt_frame.o:klatt_frame.c:(.text+0x19): undefined reference to `_gensym' > klatt_frame.o:klatt_frame.c:(.text+0x2a): undefined reference to `_gensym' > klatt_frame.o:klatt_frame.c:(.text+0x3b): undefined reference to `_gensym' > klatt_frame.o:klatt_frame.c:(.text+0x4c): undefined reference to `_gensym' > klatt_frame.o:klatt_frame.c:(.text+0x5d): undefined reference to `_gensym' > klatt_frame.o:klatt_frame.c:(.text+0x6e): more undefined references to > `_gensym' > follow > klatt_frame.o:klatt_frame.c:(.text+0x304): undefined reference to `_error' same ol' linker error, likely due to missing linker flags (e.g. "-export_dynamic -shared" for linux externals) >>>> ... whatever cygwin builds call pd externals (what's >>>> the extension of e.g. $PD_ROOT/extra/expr.* ?). >>> ==================================== >>> dhowe@wonderdog /cygdrive/c/pd >>> $ ls extra/expr* >>> extra/expr-help.pd extra/expr.dll extra/expr~.dll >>> >>> extra/expr~: >>> LICENSE.txt makefile vexp.lib vexp_fun.obj >>> vexp_if.pd_linux_o >>> README.txt vexp.c vexp.obj vexp_fun.pd_linux_o >>> expr.dll vexp.exp vexp.pd_linux_o vexp_if.c >>> fts_to_pd.h vexp.h vexp_fun.c vexp_if.obj >> >> odd... looks like you've got both .dll and .lib. afaik, .lib is a static >> library and .dll a dynamic one. pd externals are (at least on linux and >> osx) dynamic libraries: i'm guessing .dll is the way to go... anyone on the list know why both .lib and .dll get built on windoof? also, what the heck are the .pd_linux_o files we're seeing here? >>>> afaik, pd (vanilla) doesn't build or require any libraries (except maybe >>>> "-lm"). i don't use pd-extended, so i can't tell you there... if there >>>> are any global pd libraries, you'll probably need to link them in. >>> these are the libs I find in pd: >>> =============================== >>> dhowe@wonderdog /cygdrive/c/pd >>> $ find . -name *.lib -print >>> ./bin/asiolib.lib >>> ./bin/pd.lib >>> ./bin/pdtcl.lib >>> ./bin/pthreadVC.lib >>> ./bin/tcl84.lib >>> ./bin/tclstub84.lib >>> ./bin/tk84.lib >>> ./bin/tkstub84.lib >>> ./extra/bonk~/bonk~.lib >>> ./extra/choice/choice.lib >>> ./extra/expr~/vexp.lib >>> ./extra/fiddle~/fiddle~.lib >>> ./extra/loop~/loop~.lib >>> ./extra/lrshift~/lrshift~.lib >>> ./extra/pique/pique.lib >>> ./extra/sigmund~/sigmund~.lib >>> ./lib/asio/asiolib.lib >>> ./src/pthreadVC.lib >> >> ... so you might need to link in any or all of the libs in bin/ ... >> getting the order right could be tricky though. in general, gcc likes >> "highest-level" libraries left-most in the list. my guess would be >> something like "-lpd -lpdtcl -ltk84 -ltkstub84 -ltcl84 -ltclstub84 >> -lasiolib -lpthreadVC" ... but I might be wrong. >> > I seem to get that same error no matter what order I use... though if I > add a non-existent library, > it chokes on that... also if I add pd.lib as the last argument, I get a > different msg, but adding the > others doesn't help: addendum: it's probably best to add "-l" flags (aka $LIBS) at the *end* of the linker command line: "gcc $LDFLAGS -o $OUTFILE $OBJS $LIBS". also, i see no reason why we ought to need to link in both the .lib and the .dll : linking in the .dll ought to be enough, if I'm not mistaken. > $gcc -L/cygdrive/c/pd/bin -lpd -lpdtcl -ltk84 -ltkstub84 -ltcl84 > -ltclstub84 -la > siolib -lpthreadVC -Wall -Winline -o ratts.dll parwave.o klatt_frame.o > elements > .o squeue.o dsqueue.o rholmes.o phfeat.o pd_holmes.o alhash.o phtoelm.o > pd_phtoe > lm.o darray.o phoneutils.o trie.o text.o english.o saynum.o > ratts_keyval.o suspe > ct.o ASCII.o klatt~.o holmes.o holmes-feat.o holmes-mask.o > phones2holmes.o gues > sphones.o number2text.o rattshash.o rattstok.o toupper.o spellout.o > ratts.o /cyg > drive/c/pd/bin/pd.lib /cygdrive/c/pd/bin/pdtcl.lib > /cygdrive/c/pd/bin/tk84.lib > /cygdrive/c/pd/bin/tkstub84.lib /cygdrive/c/pd/bin/tcl84.lib > /cygdrive/c/pd/bin/ > asiolib.lib /cygdrive/c/pd/bin/pthreadVC.lib > > klatt~.o:klatt~.c:(.text+0x357): undefined reference to `_s_signal' > klatt~.o:klatt~.c:(.text+0x35f): undefined reference to `_s_bang' > klatt~.o:klatt~.c:(.text+0x713): undefined reference to `_s_list' > holmes.o:holmes.c:(.text+0x5c): undefined reference to `_s_list' > holmes.o:holmes.c:(.text+0x70): undefined reference to `_s_bang' > holmes.o:holmes.c:(.text+0x283): undefined reference to `_s_list' > holmes.o:holmes.c:(.text+0x3df): undefined reference to `_s_list' > holmes-feat.o:holmes-feat.c:(.text+0x3b): undefined reference to `_s_list' > holmes-feat.o:holmes-feat.c:(.text+0xd9): undefined reference to `_s_list' > holmes-mask.o:holmes-mask.c:(.text+0x7a): undefined reference to `_s_list' > holmes-mask.o:holmes-mask.c:(.text+0x3c2): more undefined references to > `_s_list > ' follow > ... ok, so it looks like we're getting at least the functions resolved by the linker (no more complaints about gensym()), but the constant symbols still aren't getting resolved... ideas, anyone? marmosets, Bryan -- Bryan Jurish "There is *always* one more bug." jurish(a)ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology

2 2

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 June 2008