Pd-dev October 2009

pd-dev@lists.iem.at

18 participants
74 discussions

UTF-8 for pd-devel (again)
by Bryan Jurish 20 Jan '10

20 Jan '10

moin folks, I believe I've finally got pd-devel 0.41-4 using UTF-8 across the board. So far, I've tested message boxes & comments (g_rtext), as well as symbol atoms, and all seems good. I think we can still expect goofiness if someone names an abstraction using a multibyte character when the filesystem isn't UTF-8 encoded (raw 8-bit works for me here too), but I really don't want to open that particular can of worms. So I guess I have 2 questions: (1) what should I call the generic UTF-8 source files? (see my other post) (2) shall I commit these changes to pd-devel/0.41-4, or somewhere else, or just post a diff (ca. 33k, ought to be easier to read now; I've tried to follow the indentation conventions of the source files I modified)? marmosets, Bryan -- Bryan Jurish "There is *always* one more bug." jurish(a)ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology

5 13

Re: [PD-dev] [flext] Fwd: fixing Flext for 64-bit?
by Spencer Russell 14 Jan '10

14 Jan '10

Attached is a patch that should make flext buffer handling 64-bit compatible. It adds new wrapper functions buffer::Peek(int index) and buffer::Poke(int index, t_sample value) to access a buffer's data. New externals should uses these instead of accessing the data array directly, because with newer PDs that doesn't work. I've also updated the buffer1 example to use the new API wrappers. The issue is that arrays in PD are of type t_word, which is a union that can contain a variety of data, including pointers. In 32-bit architectures you can pretty much ignore that it's a union because floats and pointers are the same size, but on 64-bit architectures it's important to use the w_float member of the union to access stored floats. This patch shouldn't break any old externals unless they're used with PD > 0.41 (but then they'd be broken, anyways). I don't have access to an OS X machine or Max/MSP, so I've so far only tested this on 64-bit linux/PD. YMMV. Can someone explain to me why pd's arrays are arrays of t_word instead of t_sample? -s- On Thu, Oct 1, 2009 at 10:41 AM, dmotd <dmotd(a)gmx.net> wrote: > hi spencer, > > afaik there hasn't been any progress with > the 64bit translation, i was going to > attempt it last time i needed it but got > distracted along the way - and i sent a > similar message to thomas at the time, so > its going to be on his todo list, but > proabably not a priority. > > i'd be happy to test any changes you > make, and collaborate time permitted. > > ciao, > > dmotd > > Spencer Russell wrote: >> Thought this should probably go to the list: >> >> ---------- Forwarded message ---------- >> From: Spencer Russell <spencer.f.russell(a)gmail.com> >> Date: Tue, Sep 29, 2009 at 11:13 AM >> Subject: Re: fixing Flext for 64-bit? >> To: Thomas Grill <gr(a)grrrr.org> >> >> > >> > Am 29.09.2009 um 15:00 schrieb Spencer Russell: >> > >> >> Hi Thomas, >> >> >> >> I'm writing a Flext external to implement Iannis Xenakis's Dynamic >> >> Stochastic Synthesis, and running into some problems with buffer >> >> handling on my 64-bit system. >> >> >> >> It seems that currently flext uses the deprecated >> >> garray_getfloatarray() function and t_sample arrays, instead of the >> >> new garray_getfloatwords() function with t_word unions. >> >> >> >> Changing the code would make flext incompatible with older versions of >> >> PD, but some other external developers are currently using an #ifdef >> >> workaround to change to the newer API call for PD versions that >> >> support it. >> >> >> >> I was going to get in there and see if i can't get it working in the >> >> flext code, but I wanted to check with you first to see if you had >> >> already done any work on that front. I'll of course send you the diffs >> >> if i get it working. Shouldn't be that hard and i think it should >> >> really only effect the buffer-handling code, but I don't know the >> >> flext codebase that well so there might be some hidden gotchas. >> >> >> >> -spencer >> >> On Tue, Sep 29, 2009 at 9:08 AM, Thomas Grill <gr(a)grrrr.org> wrote: >> > Hi Spencer, >> > i know that this is something i should work on, but my schedule is insanely >> > tight and i don't get to it. >> > So, if you can make any contributions and testing on 64-bit systems i'd be >> > very grateful. >> > I'd also go for the Pd API selecton by #ifdef statements. >> > gr~~~ >> > >> >> As far as i can tell, PD since 0.41 changed arrays to be arrays of >> t_words instead of t_samples or t_floats. >> >> On 32-bit architectures they're all the same size, but on 64-bit >> architectures t_word is 64-bit, while t_sample and t_float are still >> 32-bit. >> >> For a normal PD external, it's pretty easy to just modify the external >> to use t_words, but I'm not sure the best way to modify flext to do >> this without breaking compatibility for externals. One problem is that >> when an external calls mybuffer.Data(), what should they receive? if >> the system is PD newer than 0.41, they should receive a pointer to >> t_word, but MAX or older PD should receive a pointer to t_sample. >> >> The other problem is that accessing an element for newer PD requires >> accessing the w_float member of the t_word union, but the others just >> use the element itself. >> >> There could be some sort of GetValue() wrapper for buffer elements >> that could be made cross-platform, but would break compatibility with >> existing flext externals, so that seems seriously sub-optimal. >> >> thoughts? >> >> -s- >> _______________________________________________ >> http://grrrr.org/ext/flext >> >> flext mailing list >> flext(a)grrrr.org >> http://www.parasitaere-kapazitaeten.net/mailman/listinfo/flext >

2 3

[declare] bug (id 2251387)
by Roman Haefeli 26 Dec '09

26 Dec '09

hi everyone i once posted a bug to the tracker and it still appears to be there in version 0.42.3. since this bug is kind of viral, so that it corrupts patches invisibly and without being noticed by the author, and also since quite some of my own patches got affected by that bug, i would like to ask to raise the priority of this one. BEWARE: everyone, who was working on patches in 0.42.X, that contain abstractions containing [declare]'s is most likely affected, or i should rather say: infected. read the description here: http://sourceforge.net/tracker/index.php?func=detail&aid=2251387&group_id=5… roman ___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

3 3

compiling pd-extended for ubuntu 9.10
by patrick 18 Nov '09

18 Nov '09

hi, i have this error when compiling pd-extended for ubuntu 9.10: make -C /home/psc/src/pd/externals/gem2pdp make[3]: Entering directory `/home/psc/src/pd/externals/gem2pdp' g++ -fPIC -DPD -O2 -funroll-loops -fomit-frame-pointer -ffast-math -Wall -W -Wno-unused -Wno-parentheses -Wno-switch -DGEM2PDP_VERSION=\"0.7\" -g -g -O2 -I/home/psc/src/pd/pd/src -I. -I/home/psc/src/pd/externals/pdp/include -I/home/psc/src/pd/Gem/src -o gem2pdp.o -c gem2pdp.cpp In file included from /home/psc/src/pd/Gem/src/Base/CPPExtern.h:20, from /home/psc/src/pd/Gem/src/Base/GemBase.h:20, from gem2pdp.h:13, from gem2pdp.cpp:11: /home/psc/src/pd/Gem/src/Base/GemVersion.h:13: warning: type qualifiers ignored on function return type In file included from /home/psc/src/pd/externals/pdp/include/pdp.h:41, from gem2pdp.h:15, from gem2pdp.cpp:11: /home/psc/src/pd/externals/pdp/include/pdp_types.h:50: error: redeclaration of C++ built-in type Â‘boolÂ’ make[3]: *** [gem2pdp.o] Error 1 make[3]: Leaving directory `/home/psc/src/pd/externals/gem2pdp' make[2]: *** [gem2pdp] Error 2 make[2]: Leaving directory `/home/psc/src/pd/externals' make[1]: *** [externals_install] Error 2 make[1]: Leaving directory `/home/psc/src/pd/packages' make: *** [install] Error 2 also i had to modified: char * extension = strrchr(filename, '.'); for char * extension = strrchr(const_cast<char*>(filename), '.'); as reported by ClaudiusMaximus http://www.mail-archive.com/gem-dev@iem.at/msg00236.html pat

5 21

Re: [PD-dev] [PD] pd-extended build on 9.10
by András Murányi 10 Nov '09

10 Nov '09

On Sat, Oct 31, 2009 at 5:13 PM, olsen <sesselastronaut(a)googlemail.com>wrote: > buenas > ydegoyon(a)gmail.com wrote: > >> ola, >> >>> >>> /usr/lib/pd/extra/pidip/pidip.pd_linux: >>> /usr/lib/pd/extra/pidip/pidip.pd_linux: undefined symbol: >>> quicktime_has_video >>> pidip: can't load library >>> >>> >>> it's been a long time i haven't seen this one >> this means that you load pidip before loading pdp, >> or you don't load pdp at all >> > i guess this was because my brain was building this trunken package as hans > indicated. > so now i'm trying to follow the instructions on build & whoop: > > gcc -DPD -Wall -W -Wstrict-prototypes -Wno-unused -Wno-parentheses > -Wno-switch -fPIC -O2 -funroll-loops -fomit-frame-pointer -ffast-math > -DPDP_VERSION=\"0.12.5-darcs\" -I. -I/usr/X11R6/include -I../include > -I../../include -I/home/olsen/pd/pd-extended_2/pd-extended/pd/src -o > pdp_bitmap.o -c pdp_bitmap.c > pdp_bitmap.c:41: error: conflicting types for ‘pdp_packet_bitmap_isvalid’ > ../../include/pdp_bitmap.h:90: note: previous declaration of > ‘pdp_packet_bitmap_isvalid’ was here > make[5]: *** [pdp_bitmap.o] Error 1 > > any bughunter knows this one? > salutis > ø > > > I'm standing at the same one (on amd64). Andras

5 16

LogicalRealtime needed (was Re: [PD] packOSC TimeTag realtime vs. logicaltime)
by Winfried Ritsch 05 Nov '09

05 Nov '09

Hello, Sending audio over OSC needs a accurate time-tag in sync with Audio on the sender so packages can be ordered, and re-sampling with the audio-sync on the receiver, but OSC is defined to use the universal sync the Internet time (realtime). Syncing computers over Internet time is already a solved problem;using adequat audio buffer there should be a stable solution. Since Audiotime is not in sync with real-time. So we need a Locgical-Realtime on the sender, that means realtime corrected with the offset in the audio buffer processing, which should be fairly excat enough. The question is now: a) How can I get the offset of the actual audio-buffer processing to either the ADC-time oder DAC time, the the time at the beginning or end of the audio- buffer in PD ? a)if not possible Should we invent for this purposes a LocalRealtime for each audio-buffer and how ? mfG Winfried Ritsch On Friday, 9. October 2009 05:54:25 Martin Peach wrote: > Wolfgang Jäger wrote: > > Hello, > > > > I'm using a combination of [pack~] [packOSC] -> transmission(UDP) -> > > [unpackOSC] and a modified version of [unpack~] to send Audio over OSC. > > The OSC packages are sent as Bundles so a TimeTag is generated at the > > sender's side. I extended the [unpackOSC] object with another outlet > > where I'm getting the particular TimeTag of each Bundle. > > In the modified version of [unpack~] I evaluate these TimeTags with > > regards to dropouts in the transmission. > > My problem is that the TimeTags are not accurate, what I ascribe to the > > fact, that the TimeTag in [packOSC] is generated as "real time" instead > > of "logical time". Using "real time" the TimeTag-"Output" is a function > > of the audiobuffersize (depending on the cpu load), so in my case, as > > the CPU-load is quite big, the values of the TimeTags are not useable > > for sequencing the datastream (as there are jumps in the TimeTag I > > always assume some packages got lost). > > As a workaround I established a sequence number, which is additionally > > transmitted in each Bundle. This is an appropiate solution, but it > > wouldn't be necessary if the TimeTag would be generated properly. > > Are my considerations conclusive? > > At the moment the timetag is calculated when the bundle is opened with > the [ message. If the ] message doesn't occur at the same time the > timetag will be wrong as the message doesn't start to get sent until the > bundle is closed. Then there is the delay in the OS as it schedules the > packet for the network and the network card deals with possible > collisions with other packets, etc... > As well, anything [packOSC] does occurs between audio blocks (and may be > postponed if there is too much going on), so the timing will be jittery > unless your packets are being composed and sent in precise sync with the > audio. And if they are being sent to another machine with another clock > of course this is never going to happen unless you can sync their sound > cards via SPDIF or word clock. But that's real time. > Because there is no way to know what the 'logical time' is outside of > your logical frame, just use the sequential block number as your logical > time. Pack a sequence number followed by a blob, possibly resetting the > sequence numbers when they get too big. No need for bundle or timetag. > > Martin > > _______________________________________________ > Pd-list(a)iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > -- -- - ao.Univ.Prof. DI Winfried Ritsch - ritsch(a)iem.at - http://iem.at/ritsch - Institut fuer Elektronische Musik und Akustik - University of Music and Dramatic Art Graz - Tel. ++43-316-389-3510 (3170) Fax ++43-316-389-3171 - PGP-ID 69617A69 (see keyserver http://wwwkeys.eu.gpg.net/) --

2 1

Re: [PD-dev] pd.tk question
by Hans-Christoph Steiner 31 Oct '09

31 Oct '09

On Oct 30, 2009, at 10:24 PM, Ivica Ico Bukvic wrote: >> Hey Ivica, >> >> Just make it a global, that's the easiest. Or use namespaces and >> namespace variables. >> >> .hc > > I am not all that good with tk. Only learned what I had to to hack > together better version of pd.tk. Any examples would be most > appreciated. How do namespaces work? > > Also, after opening tons of windows that generate global variables, > doesn't this effectively produce a minor but nonetheless present > memory > leak as the global variables will be hard to trace when deallocating > those windows (see my other email re: improvements)? > > Ico Look at the new pd-gui-rewrite branch, it uses namespaces a fair amount. They are a bit overcomplicated in Tcl, but you don't have to use the complicated parts. .hc ---------------------------------------------------------------------------- kill your television

2 2

s_audio_jack.c patch
by Ivica Ico Bukvic 31 Oct '09

31 Oct '09

The following patch fixes jack auto-connect problem encountered on Ubuntu 9.04. Best wishes, Ico

1 0

pd.tk question
by Ivica Ico Bukvic 30 Oct '09

30 Oct '09

Hi all, Is there a way to declare a variable within a proc scope so that it can be referenced later externally? e.g. having $name.something in pdtk_canvas_new linked to a widget can be easily referenced later from another function (e.g. this is how scrollbars work). However if I want to declare a generic variable that is linked to the same scope (e.g. set $name.somevar 1), I cannot figure out how to reference this thing back from a different scope. Any ideas? Best wishes, Ico

2 1

Re: [PD-dev] Building extended on amd64
by András Murányi 29 Oct '09

29 Oct '09

> Hmm, strange, try adding a number to the >>>> packages/linux_make/debian/control file, it could look something like this: >>>> >>>> Version: 0.42.5~cvs1-1 >>>> >>>> >>>> .hc >>>> >>> >>> It's already there... >>> >>> Andras >>> >>> >>> >>> Note that i have packages/linux_make/build/debian (lower case) >> >> Andras >> <control> >> >> >> packages/linux_make/build/debian is the template, the other is the >> actual file used. So it needs to be the actual file: >> >> >>>> /home/muranyia/Download/pure-data/packages/linux_make/build//DEBIAN/control >>> >>> >> > Sorry, I'm terrible! > So the actual file shows: > >> Version: 0.42.5-extended >> > > Shall I change it to Version: 0.42.5~cvs1-1 ? > > Andras > <control> > > > Yes? You don't need to ask, just try it! > > .hc > Well, actually, build/DEBIAN/control is created when it's too late to change anything in it. Make package doesn't allow me to resume after error (no surprise), vut before make package there is no build directory. Andras

2 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 October 2009